This adds a new field, CScript rewardScript, to the masternode data
structures.  For now, we just add it, return it from the RPCs, and
set it to the script corresponding to the collateral pubkey on
creation.

We also serialise the new field as part of CMasternode, which is used
e.g. in the on-disk cache, but not the wire protocol (where
CMasternodeBroadcast is used instead).  Thus this change invalidates the
mncache format, but has no other effects on compatibility.

In the future, we will implement a protocol upgrade and also network
fork that will use this new field so masternodes can specify an arbitrary
script to which they want to receive their payments, rather than being
paid always to the collateral address.

Define a new wire protocol version, and for peers that match the
version, send the reward script as explicit part of the masternode
broadcast messages.

Also, if the reward script is not the default value, include it in the
signature message of the broadcast (so that the field is authenticated
by the collateral signature).

Until the protocol version is bumped on the network (which is not yet
the case with this commit), masternodes with non-default reward script
will not be accepted as valid.

Instead of using the collateral pubkey, pay to the declared reward
script of masternodes (and use that to check payments).

This extends the setupmasternode RPC method so that it allows setting
a non-default reward address.  The reward address is an optional sixth
argument following the ip_address.

Use a custom reward address for one of the two masternodes in the
mnoperation.py regtest, verifying that this works.

For the test, we activate the new protocol version on regtest without
any forking logic.

Custom reward addresses are one of the core features needed for
proper masternode vaults.  With them implemented now, we can update
the mnvaults.py test (resolving two FIXME's in there) to actually make
use of an explicit reward address so that the masternode rewards are
received and not lost (as we want them to be in practice).

This defines a new time-activated "fork", Fork::CustomRewardAddresses.
For now, it is scheduled at timestamp 2000000000; that will be set to
the actual activation time once it is determined.

When this fork becomes active (i.e. the current best block's timestamp
goes beyond the activation time), we require peers to use the new protocol
version that supports custom reward addresses.  The fork has no other
(in particular, no consensus-level) consequences.

This adds a new regtest, custom_address_update.py.  The test runs
two masternodes, where we explicitly set the protocol version of
one of the nodes to the "old" version not supporting custom reward
scripts for masternodes.

With this test, we ensure that all the masternode networking works fine
between "old" and "new" nodes before the update is activated, at least
as closely as we can without running a real old node.